Видео

I feel like result represents a genuine failure of the function more than option. For instance, HashSet::get does not always have a value for a certain key and that is expected behavior when consuming that API. In contrast, parsing a string and getting a UTF8Error is not something that you would expect to happen and signals that a genuine exception can happen. HashSet::get can not fail in the same way since a None return is expected behavior sometimes and not considered an error like a string parsing error. Do you agree?

i wish i were good enough at rust to care about things this meaningless 💀

That's an eye-opening way to think about rust. Great work.

Two-phase initialization was popular in Java so we have a bunch of legacy C++ that has initialize() and finalize() methods. Really ugly. Plus we’re stuck on ‘17 so no designated initializers 😢

I love the way you talk about hugely complex things in such a clean and clear, understandable way. One of the best rust channel on yt

Man you have to sit in to get the point of these videos.

9:22 isn't that similar to how most languages use exceptions, though?

This is not how Cpp does dynamic dispatch. Cpp has no rules how polymorphism must be implemented.

First let me thank you for that public_cast code. I never knew Cpp allowed that. I had a raw_cast that I had to implement class by class. Now I can just use public_cast and not have to manually implement anything. Second thing is; I always use C style cast, unless I need a specific cast. And I always use C style cast as a static cast or dynamic cast.

I watch this video every time I'm about to write a library to remind myself how to do it right, and every time I learn and remember a bit more. My journey of errors was Box<dyn Error>, anyhow, thiserror, and I'm probably right in that most crustaceans go through this cycle lol. Great vid, thanks. Wish I had it when I started with rust.

Rust indirections is three as well since functions need access to the object in 99.9% of cases.

Where can I buy your Rust course?

Thank you! SplineCraft PRO plugin is advanced tool that available in the Marketplace - it also solves similar problems.

SplineCraft PRO plugin is advanced tool that available in the Marketplace - it also solves similar problems.

I watch this video once a month

… and you just single handedly convinced me to like & subscribe with the bell turned to the max without even asking. Is it a (TotalSubscriber*) randomViewer? 🤔🤔🤔

You don't need Rust in C++, you just need to use Rust.

Sounds like a good rule of thumb would be this: could you replace each AddPoint with AddPoints on a 1-sized array without a performance drop (irrespective of the heap allocation)?

I don't really think that the performance issue in C++ has to do with the fact that functions are "structurally typed". Sure, having a unique type for each function would simplify the optimization, but I'd fully expect the compiler here to acknowledge that you are passing the same function each time. It does so for normal values, so why not functions? Regardless, it is relatively uncomplicated to fix this without changing too much of your code, here's just quick code that I wrote that should help: template <auto Func> constexpr const inline auto monomorphic = [](auto&&... args) { return Func(std::forward<decltype(args)>(args)...); }; Using monomorphic<f> instead of f gives you the benefit of the lambda type, while not sacrificing much of readability or conventions.

Pedantic complaint about the compiler's wording ‒ "no two closures, even if identical, have the same type" is technically incorrect. In the following code: let mut local = |x: i32| x; let local2 = local; local = local2; assert!(local.type_id() == local2.type_id()); The variables "local" and "local2" are our two closures, obviously "identical" (meaning "one and the same") since they come from the same definition, yet one can be assigned to the another, and their types are equal. It would be better to say something like "the type of a closure is unique and is not equal to the type of any other closure, even with equivalent definition".

this video makes me glad that I'm not smart enough to know C++

why have you marked the c++ function no-inline and then complained about the function not inlined(?) makes no sense to me basically, this example you wrote is perfectly inlinable and the generated code should be almost the same as the rust one upd: I found the explanation comment

I would use ArrayString stored on the stack so you have copy trait and can forget about ownership

I really enjoyed this video, I've used a bunch of languages with constructors (C++, Java, C#) and have been using Rust for a little while now. The other day, I had a little C# to write, and when working with constructors I felt a familiar tiny little pang of dread again, and I think you just nailed down what I was feeling. The metaphor that a constructor is a function that returns an initialised object isn't quite true, and it's in the details where some subtle ambiguities and bugs often lie. Rust applies the metaphor much more literally, and I feel a lot more confident in what I'm doing. Funnily enough, this is one of the things I've appreciated the most with Rust. There are much fewer "things" to consider in the language. It's closer to C in many ways in that regard.

One of the biggest learning curves I've experienced, going from languages like Python on JS to rust, is forcing myself to trust the compiler. I don't have to do anything convoluted, I just write code and the compiler does its job. This video is a good example of that

epic video

5:09 this breaks my brain

Fantastic video explaining the algorithm and it's implementation!

Talking about Rust and C++ in the same video without bagging one out as superior to the other? Inconceivable! 😂

11:39 what "int C::*" mean ?

What the hell. I am never using c++. Not fking worth it.

I want Joe Biden to be youtuber

Just a small tip: you started talking about monomorphization as if everybody knows what that means. I had to look it up.

Somehow C-style 'type(value)' casts always felt most aesthetic to me since it just looks like a function you give some other data type as an argument that then turns into the data type the function is named after.

Maybe using consteval ?

I don't do Rust but I like these great quality videos, however I'm a little critical on the part about returning direct references and applying that to other languages like C++. In C++ that probably isn't the best idea because you can end up with UAF bugs because a lot of times (especially returning views from functions) the view will live longer than the actual object that allocated the memory. Is that not a problem in Rust because of the borrow checker?

I'll go one further... monster name strings likely are static anyhow, and so you don't even need Arc<str> or Box<str>, you can just use str directly. Then clones don't even need to increment a reference count on the heap, you just copy the pointer.

Coming from c++ newly to rust, a few things don't make sense to me in this explanation. maybe someone can explain: - since we're talking about immutable vecs and string slices, why do we care for thread safety? if it can't be changed from either thread, we might as well just use Rc - even using just rc doesn't really make sense to me. after all, vectors and strings are already smartpointers. so wrapping them in another smartpointer just creates an unnecessary indirection. the clone should still be O(1) since if i understand correctly only stack metadata is copied, and copying 24 bytes instead of 16 really shouldn't make a big difference on modern cpu's - string slices in rust are probably implemented the same way as in c++, which would be ptr + size or a total of 16 bytes on x64. the compiler usually passes such small structs in registers, meaning passing a str directly without wrapping it in a smartpointer will always be faster. that's the whole point of slices actually. since the data likely resides in the rodata section of the binary, its lifetime is static furthermore, so it should always be valid.

Yes please, more interesting Rust content

I'd prefer a Cow<str>.

ty - i like rust more and more once things are explain ed like this

nice work

It's been very hard for me to decouple a lot of these very atomistic subjects from my original understanding of them coming from Java. All of these disparate concepts being baked in and "solved" with Java's particular inheritance model. The entire time I'm thinking to myself "Rust doesn't have simple interfaces?" xD I'm learning though, every day.

Interesting interesting

Yo! This one is pretty usefull and there are not a lot of usefull geometry script videos on you tube. So thanks.

Do calls to NonZeroU8::new just get optimized out, because in memory it returns the same thing as it receives? If so, why would NonZeroU8::new_unchecked be necessary

What if there's more than one failure?

So basically, all of the C programmers that use "null" have just been justified . But regardless, that's actually correct. Ideally, you want Rust to compile identical to C, but simply give you type-safety around your otherwise unsafe C code. C's NULL acts like an Optional<&T>, so you should use the same type in Rust.

Just use C++ 🤷‍♂️

I would argue that if you are exposing the function data_mut(&mut self) -> &mut Option<Data>, and you want to provide an immutable accessor, you should use data(&self) -> &Option<Data> for consistency. Though data_mut would be a somewhat strange method, and if you're already breaking encapsulation to that point you may as well just make your data field public.